Re: Security Problem ftpd (includes wu.ftpd 2.4 and 2.4.2 beta 4)
Jeremy Fitzhardinge (jeremy@sour.sw.oz.au)
Thu, 13 Jul 1995 19:12:14 +1000
> On Wed, 12 Jul 1995, Henri Karrenbeld wrote:
> > l-wx------ 1 <yourname> 64 Jul 12 13:07 5 -> [0301]:24718
> [snip]
> > So normal access for wtmp is 644, however this 'hard link' into the filesystem
> > points directly to the inode (24718) and gives you write access to this file
> > by writing to /proc/2728/fd/5 instead of to /var/adm/wtmp.
>
> Just like to ask a stupid question. Is "5 -> [0301]:24718" a hard link or
> is it a soft link? (sorry..i dont have the spec for /proc filesystem..)
It's not really a link at all. If you open it, the FD you get is either
the same as reopening the original file (even if it has no existing name),
or a dup of the fd. Which is it depends on the exact Linux version, and
how it was compiled.
Also, it is not necessary to know the pid of the ftpd to find its proc
entry; you can just use /proc/self find it.
> If it is a hard link, then we are in deep trouble. If i am not wrong,
> /proc/<processid>/exe is also a link which actually points to the inode
> of the program of the process. This means that anyone can overwrite or
> modify any program they run by 1.
> run the program and then suspend it
> 2. ps and look for process id 3. Overwrite /proc/<processid>/exe with
> their trojan version.
Linux does not let you modify the executable of (or shared libraries
in use by) a running program, even root.
However, it may be possible for someone to transfer /proc/self/mem,
which is the memory image of the ftpd, and peruse it at their
leasure. This may reveal things like scraps of /etc/shadow, or
more seriously, actual passwords; perhaps not a problem, unless
you leave an open FTP session and someone walks up to it and finds
your password in the ftpd's address space.
It may also be possible to download a new /proc/self/mem to change
the behaviour of the running ftpd, but I suspect this would be hard
without crashing the ftpd as it runs.
It is not, however, possible to control processes (stop, run, breakpoint,
change registers, etc) through /proc; you need to run the ptrace syscall
(SITE PTRACE anyone?).
The short answer is: don't allow /proc access to any ftp user.
Does the wuftpd have some mechanism to disallow all access to
certain paths? Note that new kernels fix all these problems:
processes which were once running with euid!=uid are considered to
be "tainted", and all their proc entries have restricted access
(under Linux 1.3.8 ftpd's sensitive /proc entries are all only accessable
by root)
Also note that an ftpd running as a user will have access to the /proc
entries of all other processes running as that user, and so can inspect
and/or modify their memory images, file descriptors, cwd, etc.
If you have /proc mounted in a chrooted area (a *VERY* bad idea),
this would allow an ftp user to easily escape through any process's
cwd, root, or open directory /proc entries. It would also allow
(with SITE EXEC) the ftp user to start a new instance of any
accessible running process (with /proc/pid/exe).
J
--
Powerful tools have sharp edges.